As the world becomes more dependent on network-based services for critical applications, particularly via Transmission Control Protocol/Internet Protocol (TCP/IP) networks, it becomes more vital to protect Domain Name Systems (DNS) from attacks and failures. Unfortunately, popular DNS implementations are known to be targeted based on numerous vulnerabilities, exploits and attacks.
DNS is essentially a distributed database. Each name server can maintain domain name information regarding a subspace, or a zone, in the DNS name space. Several predefined properties, or resource records (RR), can be associated with a domain name. An example of an RR is “type A” RR, which may contain an IP address of the domain. Generally, RRs pertaining to domain names in a zone are stored in a master file, which can be maintained by the primary name server of such zone. Each zone can also have one or more secondary name servers, which can periodically synchronize their local DNS file with the master file. Ordinarily, secondary name servers respond to DNS queries. However, they may not be involved in maintaining the master file.
The DNS architecture was later enhanced with DNS Security Extensions (DNSSEC) to provide data origin authentication. With DNSSEC, each zone can be equipped with at least a pair of public and private keys. The public key may be configured into every client in the zone through a safe channel (e.g., manually by administrators). The private key may be used to digitally sign RRs. A response to a DNS query may include requested RRs and a digital signature of the requested RRs, which is also known as “Sig RR.” DNS clients can verify the integrity and origin of received DNS data by checking accompanying signatures using the zone public key.
The integrity of the above approach may depend on the secrecy of participating private keys. Maintenance of private keys is usually maximized by keeping them offline. In this position, even if a server is compromised, a hacker is not likely able to procure the private key and temper with DNS data. However, the hacker may still be able to attack the server in other respects, such as deleting the master file as a denial of service attack or using the server as a jump pad to machines inside the intranet.
Additionally, it is preferable to have signature computations offline. This position may best suit domain names that are created and managed manually via administrative procedures (e.g., one registers for a new domain name, fills out a form, pays a fee, etc.). Offline signature computation, however, may not be compatible with dynamic domain name updates, where RRs can be updated in real time upon online requests from clients.
Under DNSSEC standards, different modes can be used to compute signatures of dynamically updated RRs. In Mode A, a per-server private key is used to sign dynamic updates. The corresponding public key is stored in a Key RR associated with the domain name of the server. This key may be obtained by the client through DNS requests. In this way, server compromises can only jeopardize dynamically updated resource records. However, server keys are not typically considered as authoritative zone keys. In Mode B, the zone private key may be kept online and used to sign dynamic updates. This feature may leave the key subject to exposure through network attacks. In the face of server compromises, the integrity of the entire master file may be in question.
In addressing these problems, what is needed is a secure framework of DNS servers that does not require private keys to be kept online to sign dynamic updates. Also, it is desirable to have a secure framework that would hinder further attacks on the server. Such framework can help maintain the availability and integrity of any critical communications infrastructure.